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REMARKS 

Claims 1-31 were originally presented in the subject application. Claims 1,11 and 22 
were amended, claims 2, 12 and 23 were cancelled, and claims 32-50 were added in a 
Preliminary Amendment dated July 23, 2003. No claims have herein been amended, added 
or canceled. Therefore, claims 1,3-11, 13-22 and 24-50 remain in this case. 

Request for Information 

The Office Action noted a number of items listed in the specification, and 
incorporated by reference, requesting copies thereof for consideration. Unfortunately, only 
two were present in the undersigned's file and are included herewith. Applicants note that 
the requested item entitled, "CORBA A Guide To Common Object Request Broker 
Architecture," by Ron Ben-Natan, McGraw-Hill Publishers (1995), was included with 
Applicants' Information Disclosure Citation filed with this continuation application. We 
have requested and received electronic copies of 1 1 of the remainder of the incorporated 
items from the assignee and are enclosed herewith on a CD. The four remaining references 
will be forwarded when received from the assignee. A list of the references is appended 
hereto, indicating the status of each reference. 

35U.S.C. §103 Rejection 

The Office Action rejected claims 1, 3-1 1, 13-22 and 24-50 under 35 U.S.C. §103, as 
allegedly obvious over Held et al. (U.S. Patent No. 5,802,367) in view of Thatte et al. (U.S. 
Patent No. 6,442,620). Applicants respectfully, but most strenuously, traverse this rejection. 

Claim 1 recites a method of providing access to an object of a computing 
environment. The method comprises requesting access, by a requester, to an object located 
in an address space of the computing environment, the requester being resident within the 
address space. The method also comprises providing access to the object using a local access 
proxy located within the address space, wherein use of the local access proxy provides 
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separation of management of one or more object references to the object from management 
of one or more virtual memory copies of the object. 

Against the requesting aspect of claim 1, for example, the Office Action cites to Held 
et al. at column 10, lines 62-67. According to that aspect, the requestor and the object are 
both located in the same address space. However, a careful reading of the cited section of 
Thatte et al. and the surrounding text reveals no teaching about the location of the object 
relative to the requestor. The cited section merely teaches that if server code corresponding 
to the activation request needs to execute locally (i.e., on the server node where the code is 
located), then the client service control manager communicates directly (presumably with the 
server node). The beginning of that paragraph of Held et al. at column 10, line 35 clearly 
indicates the context of the cited section is remote accessing of an object', that is, an object 
remote from the requestor. Applicants submit this is quite the opposite of the object being in 
the same address space as the requestor. 

As another example, against the claim 1 aspect of use of the local access proxy 
providing separation of the management of object reference(s) from management of virtual 
memory cop(ies) of the object, the Office Action at numbered section 6 cites to Thatte et al. 
However, the facelets (and associated facelet-managing proxy manager) are only used when 
the client component application object and the server component application object are in 
different apartments (column 13, lines 42-63), which are in separate domains (column 11, 
lines 27-28). In contrast, claim 1 recites that the local access proxy is in the same address 
space as both the requestor and the object to which access is being requested. 

Therefore, for at least the above reasons, Applicants submit that claim 1 cannot be 
obviated over Held et al. in view of Thatte et al. 

Each of independent claims 11,21 and 22 contains limitations similar to those argued 
above with respect to claim 1 . Thus, the remarks above are equally applicable to those 
claims. Therefore, Applicants submit that none of claims 1 1, 21 or 22 can be made obvious 
over Held et al. in view of Thatte et al. 
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CONCLUSION 



Applicants submit that the dependent claims are allowable for the same reasons as the 
independent claims from which they directly or ultimately depend, as well as for their 
additional limitations. In that regard, Applicants do not acquiesce to the alleged teachings of 
the cited references relative to the dependent claims. 

Applicants acknowledge the references cited in the Office Action, but not 
substantively applied. However, Applicants expressly do not acquiesce to the alleged 
teachings thereof, and, in any case, submit that the pending claims are patentable thereover as 



For all the above reasons, Applicants maintain that the claims of the subject 
application define patentable subject matter and earnestly request allowance of claims 1, 
3-11, 13-22 and 24-50. 

If a telephone conference would be of assistance in advancing prosecution of the 
subject application, Applicants' undersigned attorney invites the Examiner to telephone him 
at the number provided. 



Dated: February 2, 2006. 

HESLIN ROTHENBERG FARLEY & MESITI P.C. 

5 Columbia Circle 

Albany, New York 12203-5 160 

Telephone: (518)452-5600 

Facsimile: (518)452-5579 



well. 



Respectfully submitted, 




Wayne F. Reinke 
Attorney for Applicants 
Registration No.: 36,650 
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Appendix A 

Status of Providing Copies of References as Listed in the Specification 



Page 


Title 


Status 


13 


"Enterprise Systems Architecture/390 Principles of 
Operation", IBM Publication No. SA22-7201-05, Sixth 
Edition (Sept. 1998) 


Awaiting Hard Copy 


14 


CORBA A Guide To Common Object Request Broker 
Architecture, by Ron Ben-Natan, McGraw-Hill Publishers 
(1995) 


Enclosed 


14 


Object- Oriented Programming Using SOM and DSOM, by 
Christina Lau, Van Nostrand Reinhold Publishers (1994) 


Awaiting Hard Copy 


14 


"CORBA 2.2/IIOP Specification," available at 
WWW.OMG.ORG/library/C2INDX.HTML 


Enclosed 


15 


"Component Broker Programming Reference Release 2.0," 
IBM Publication No. SC09-28 10-04 (Dec. 1998) 


Trying to Locate 


15 


"Component Broker Programming Guide Release 2.0," 
IBM Publication No. GO4L-2376-04 (Dec. 1998) 


Trying to Locate 


15 


"Component Broker Advanced Programming Guide 
Release 2.0," IBM Publication No. SC09-2708-03 (Dec. 
1998) 


Trying to Locate 


16 


"MVS Programming: Assembler Services Guide," IBM 
Publication No. GC28- 1762-01, Second Edition (September 
1996) 


Enclosed on CD 

Original Not Available - Updated 
Version Provided 


16 


"MVS Programming: Assembler Services Reference," IBM 
Publication No. GC28-1910-01, Second Edition (September 
1996) 


Enclosed on CD 

Original Not Available - Updated 
Version Provided 


54 


"OS/390 MVS Planning: Workload Management," IBM 
Pub. No. GC28- 176 1-07 (March 1999) 


Enclosed on CD 


54 


"OS/390 MVS Programming: Workload Management 
Services," IBM Pub. No. GC28-1773-06 (March 1999) 


Enclosed on CD 

Original Not Available - Updated 
Version Provided 
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Status of Providing Copies of References as Listed in the Specification 



Page 


Title 


Status 


54 


"OS/390 V2R5.0 MVS Programming: Resource Recovery," 
IBM Publication No. GC28-1739-02(Jan. 1998) 


Enclosed on CD 

Original Not Available - Updated 
Version Provided 


65 


"OS/390 MVS Planning: Workload Management," IBM 
Pub. No. GC28- 176 1-07 (March 1999) 


Enclosed on CD 

Original Not Available - Updated 
Version Provided 


65 


"OS/390 MVS Programming: Workload Management 
Services," IBM Pub. No. GC28- 1773-06 (March 1999) 


Duplicate 


73 


"OS/390 MVS Planning: Global Resource Serialization," 
IBM Pub. No. GC28- 1759-04 (March 1998) 


Enclosed on CD 

Original Not Available - Updated 
Version Provided 


73 


"OS/390 MVS Programming: Authorized Assembler 
Services Guide," IBM Pub. No. GC28- 1763-06 (March 
1999) 


Enclosed on CD 


73 


"OS/390 MVS Programming: Authorized Assembler 
Services Reference," IBM Pub. Nos. GC28- 1764-05 (Sept. 
1998) 


Enclosed on CD 


73 


GC28- 1765-07 (March 1999) 


Enclosed on CD 

Original Not Available - Updated 
Version Provided 


73 


GC28- 1766-05 (March 1999) 


Enclosed on CD 


73 


GC28- 1767-06 (Dec. 1998) 


Enclosed on CD 


73 


"OS/390 MVS Programming: Assembler Services Guide," 
IBM Pub. No. GC28- 1762-01 (Sept. 1996) 


Duplicate 


73 


"OS/390 MVS Programming: Assembler Services 
Reference," IBM Pub. No. GC28-1910-1 (Sept. 1996) 


Duplicate 
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The SOMObjects toolkit is an IBM product that, uStiML 
capabilities, provides a framework for developing dUtribuWiB 
oriented applications based on a CORBA-compliant OW 
heart of SOMObjects is the System Object Model (SOMg^gtffil^ 
underlying technology targeted primarily at allowing d^SSSwSi 
binary class libraries. Binary class libraries are claw IftSwiS&S 

Z e K??fw Cted U u iQg ° ne ^J^riented programming language 
and but that may be used from within another programming Ian- 
guage. Binary class libraries allow the clients and the implements 
or the classes be as decoupled as possible; the clients should not have 
to be recompiled if the implementation has changed internal!* Thl» 
type of sharing between different object-oriented development envi- 
ronments has been lacking, even though procedural libraries have 
Been providing similar functionalities. SOM provides the necessary 
support to allow the creation of such object-oriented binary class 
libraries. 

The basic enabler of such libraries is SOM IDL. SOM IDL is based 
on CORBA DDL and extends it in a number of ways necessary to sup- 
port objects in the SOMObjects toolkit. The developer defines the 
m T er Sf eS ° f the ° bjects to be Eluded in the libraries using SOM 
IDL. These definitions are translated by the SOM compiler to the pro- 
gramming language of choice, where the methods are actually imple- 
mented. Since the interfaces are defined in SOM IDL, any program- 
ming language that has a binding for the IDL may be used for both 
the implementation and the invoking client. For clients, it must be 
possible to create and invoke requests, while for object implementa- 
tions the actual methods must be implemented. The client and the 
object implementation are totally decoupled; the interfaces are 
accessed m IDL, and so the client does not care (and does not know) 
what programming language was used for the object implementation. 



275 



276 



Chapter Ten 



The delivery of the requests from the client to the object implementa- 
tion is done by the SOM runtime system (or the DSOM runtime sys- 
tem if the client and object are in different address spaces). 

SOM stresses that libraries must be binary class libraries. This 
means that SOM provides an underlying runtime system that 
ensures binary usage of the libraries. Therefore, if an implementation 
change is performed that does not require a source code change to the 
client, no recompilation of the client is necessary. Changes to the 
object interface require client recompilation, since the access routines 
used by the client may have changed. These changes, however, are 
much less common; interfaces usually stabilize early in a develop- 
ment project's life, whereas implementations keep evolving. Changes 
that do not require recompilation in SOM include even such things as 
extending the class with more methods (actually changing the inter- 
face), adding superclasses (since SOM supports multiple inheritance), 
moving methods to superclasses, and even changing the size of the 
object. Most of these changes require client awareness in most all 
other object-oriented class libraries. 

SOM ensures programming language neutrality through a series of 
design decisions. All interfaces are written in SOM IDL, and so 
clients can use any programming language that has a SOM IDL bind- 
ing to access objects implemented in any programming language (that 
has a binding). This is sufficient for allowing programming language 
neutrality, but SOM goes a step further. SOM defines a common 
object model that is used by any application using SOMObjects. This 
object model is well defined yet is flexible enough to accommodate the 
object models of most object-oriented programming languages. For 
example, method resolution is flexibly controlled by the developer, 
and multiple dispatch strategies can be fitted to the appropriate pro- 
gramming environment or application. SOM defines a standard link- 
age convention allowing any programming language that can make 
external calls to activate the SOM runtime system and access SOM 
objects. This is not limited to object-oriented programming languages; 
in fact, the first programming language to have a SOM binding was 
the C programming language. 

SOM includes a set of built-in libraries that make up the SOM run- 
time system. These classes provide the support required for the SOM 
object model, for method dispatching, for object reference manage- 
ment, and so on. The last component of the base SOM structure is the 
SOM compiler, which is used to translate the IDL specifications into a 
variety of implementation skeletons and client stubs. 

SOMObjects provide much richer capabilities than are provided by 
SOM alone. While SOM remains the central technology of 
SOMObjects, and while all the added frameworks use SOM and the 
capabilities it provides, SOMObjects provides an extensive set of 
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frameworks to be used by application programme 
infrastructure basis. These frameworks include 

■ Collection and communication classes. These provM. 
standard data structures and socket communS^ 
SOM objects that can be used by application P Sr m S?w^ 

■ The Interface Repository framework. This provides .feSf 
retrieval capabilities for interface information and iTul^S^ 
and other frameworks (e.g., Distributed SOM). It can a£i 
^application programmers who require access to metf 

■ Distributed SOM (DSOM). This is a CORBA-compliant ORbS 
mentation that extends SOM with distribution transparent k 

' Vl *? pUcation Framework. This framework allows the «mSm 
ion of groupware applications where multiple users view dwiSgRfr-- 
semantic object and participate in the manipulation of this coS'C 
view The replication framework allows objects to be assttSSSpl 
with one another as replicas of one semantic object. The fimmSSt*' 
then provides manipulation techniques that allow the synchroS^I : 
tion of the replicas; if one replica will be changed, the chan«r3fl . 
be propagated to all of the other replicas. These replicas eStta 
separate address spaces and potentially on different machine.. The 
replication framework does not use DSOM; rather, a specialist 
framework is provided for specifically supporting replicated object* 

■ The Event Management Framework. This supports event manage- 
ment and callback dispatch, which is necessary in single-threaded 
environments but is often useful even in multithreaded environ- 
ments that require certain integrity guarantees for event handling. 

■ The Emitter Framework. This allows programmers to quickly and 
easily create compilers that read IDL definitions and produce spe- 
cialized output as defined by certain templates and algorithm.. 
These are supplied by the programmer but are inserted into the 
framework in predefined procedures. This process is easy to per- 
torm, allowing multiple emitters to be created. This is useful for 
programming language binding creation but also for such things as 
producing automated documentation and information for CASE 
tools. 

■ The Persistence Framework. This provides SOM objects with persis- 
tence capabilities. 

All of these frameworks provide an initial set of classes that can 
immediately be used by application programmers. These frameworks 
are all constructed in a modular and flexible way that allows the 
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developer to extend any component by subclassing the default built-in 
class and implementing custom behavior. The frameworks are truly 
frameworks in the sense that multiple customizations are possible 
using simple replacement of different objects serving different pur- 
poses. 

This chapter describes the SOMObjects Developer Toolkit, Version 
2.0 as documented in IBM (1993a and 1993b). This version is support- 
ed on the AIX and OS/2 platforms and will be supported on other IBM 
and non-IBM operating systems including operating systems not used 
on personal computers or workstations (e.g., it will be supported on 
mainframe operating systems). The toolkit includes bindings for the 
C and the C++ programming languages; other programming language 
bindings will probably be available before this book is published. For 
example, the joint proposal for the Smalltalk-to-CORBA IDL binding 
(by HP and IBM — See Mueller, 1994a) is partly based on experience 
with binding SOM IDL to Smalltalk. Other programming language 
bindings for SOM will include non-object-oriented programming lan- 
guages like COBOL. 



10.1 The System Object Model (SOM) 



The primary goal of SOM is to allow the production of programming 
language-neutral binary class libraries. SOM is the central compo- 
nent in the SOMObjects toolkit and provides capabilities used by all 
SOMObjects frameworks. 

SOM separates interface specification and object implementation. 
Interfaces are created using the SOM IDL, while object implementa- 
tions are done in programming languages which have SOM bindings. 
Interface definitions are also stored in the SOM Interface Repository 
and may be accessed as InterfaceDef objects to be used by application 
programs or by the SOMObjects components. 

SOM is a very rich object model that can support most object mod- 
els used today. It supports the notion of classes as first-class objects 
and metaclasses as objects describing the classes (or the classes' 
class, as in Smalltalk; see Goldberg and Robson, 1983). The SOM 
runtime system manages SOM at runtime. Class objects need to be 
created at runtime so that instances may be created. The class 
objects may then be accessed at runtime as objects, and methods can 
be performed for these objects. SOM supports class derivation and 
multiple inheritance. This allows it to support programming lan- 
guages that require multiple inheritance as well as the various speci- 
fications coming out of the OMG. Many of the SOMObjects toolkit 
frameworks use multiple inheritance (e.g., see the use of multiple 
inheritance in the automatic generation of proxy classes in DSOM, 
discussed in Sec. 10.4). 



10.1.1 SOMIDL 
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Writing SOM applications involves the following: 
■ SOM IDL is used to define the interfaces and other definitions to be 

the object's clients toKSe?^ header files to be **d by 
implementation ske e £n fife that wTh! P T fT"* langUa * e) > 
mentation (which will be 'ZmlteA £ for he ob J e ^ imple- 
object in a certain programS , y tbe T lm P le ™ntor of the 
information, and more The llTt^T 1 R ^ 0sito ^ 
describes how emitters can b e 5? ter /j am ^ork (Sec. 10.7) 
translations of the ID^sp^cMcations t0 Pr ° dUCe additional 

" d 7 el r • fi^s gener- 

implemented in the Tent's pro™ "! * S ° M ° bject wer * 
the client's address Z^eTS running in 

client's program will includTqOM . CaI P rocedur e calls). The 
the management of obfects j e , tia *i zat ion code, since 
nents. ° bjects 18 done b y a set of SOM compo- 

" £^^^™*« "Pon the skeleton 

' ^L% d t^^ ar V7 PiIed 30(1 ,ink6d ' «"°** an 
with no changes* the ^SgSTSS at 3 ^ " me 

Pilation. This is true even if J ff* d ° es not re W™ recom- 
DSOM is used, the Client aid o ^ * f ^ ° 1 ** t Chan * es - 
in the same address ^^J^^^^^V 
that the client may not even h»tl ! u u , the Same ma chine, so 
mentation to change 6 to be ha]ted for 311 ob Ject imple- 

SOM IDL is based upon CORBA TnT JL 

wherever possible. A number of e*£n *» ^se definitions 

port SOM specific functSnalitfe^ *ten S10ns h beeQ added tQ 

IDL constructs should be Smited b^ ° f S0M 
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jifdef SOMIDL 

#endif 

directives, and private attributes or methods (not available in 
COBRA IDL) are delimited by 

#ifdef PRIVATE 

•endif 

Since SOM IDL is almost identical to CORBA IDL, a full descrip- 
tion of it is not provided here. Instead, a description of the major 
extensions included in SOM IDL is provided. 

SOM IDL adds two type categories to CORBA IDL data types. For 
any SOM IDL type T, the type unsigned T is allowed in SOM IDL. 
CORBA IDL only allows unsigned long and unsigned short. 
Pointer types are also introduced by SOM IDL. For any SOM IDL 
type T, the type T* is allowed in SOM IDL. 

The most important extension made by SOM IDL is the use of 
Implementation Statements. Implementation Statements specify 
implementation details and take the form of instance variable decla- 
rations, passthru statements, or modifier statements. 

Instance variable declarations use syntax similar to that of ANSI-C 
to declare class instance variables having a SOM IDL type. These 
variables are private in the C++ sense; that is, they can be accessed 
only by the class's methods. These are different from the — PRI- 
VATE directives, which are used for private IDL methods anc 

attributes. 

Passthru statements allow blocks of code to be passed unmodifiec 
to the output files generated by the SOM compiler. A passthru state 
ment specifies what result file the block should be copied to as well ai 
what the code block to be copied is. Passthru statements are providec 
primarily for backward compatibility with SOMObjects Version 1.0. 

Modifier statements are used to provide additional informatior 
about IDL definitions. They provide information about interfaces 
types, attributes, and methods. Table 10.1 details the most commonl: 
used SOM modifier statements. 

1 0.1 .2 Inheritance in SOM 

SOMObject is a class provided as part of the SOMObjects toolkit 
This class defines behavior common to all SOM objects. Any clas. 
must therefore inherit (directly or indirectly) from SOMObject. SO* 
supports the notion of class inheritance, as is common in most object 
oriented programming languages (e.g., in C++ as defined in Ellis an* 
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TABLE 10.1 SOM Modifier Statements 



Modifier 



nodata 



noset 



persistent 



callstyle=oidl 
classinit=<proc name> 



dllname=<filename> 

functionprefix= 
<prefixstring> 

majorversion= 

minorversion= 

metaclass= 

<classname> 

method 

procedure 



noooverride 
override 

offset ; namelookup 




attribute 

attribute 

attribute 

interface 
interface 

interface 
interface 

interface 



Specifies that an instance variable should not be created 

ZSVt hUte i ThG get and set accessor meth °ds are 
created for attribute access. This is used for attributes 
which are calculated and not stored 
Specifies that a set accessor methods should not be creat- 
ZS at? °M compiler; only a get accessor methods is 
created. Used for readonly (or const) attributes 
Specifies that the attribute is part of the persistent re- 
FrSework n ^ iS USed by the Pers ^ence 

Informs the SOM compiler to use old IDL style syntax 
Informs the SOM compiler of the procedure to be used for 
initializing the class object. The SOM compiler will create 
a skeleton for the procedure implementation which wOl 
be completed by the class developer 

^ -P 1 — tation is loaded f rom 
Used by the SOM compiler to prefix all methods in the 

SSU* prefix string - ^ option 13 used to 

ly resolve name space conflicts. 

Specifies the class's major and minor version numbers. 



interface Specifies the class's metaclass 



method 
method 



method 

method 
method 



Specifies that the method can be overridden. 
Specifies that the method should not be overridden and 
informs the SOM compiler to use efficient direct dL 

£££££ method instead of requirii * ™ time 

Specifies that the method should not be overridden by 
subclasses but does not have the effect on the SOM com- 
piler of changing the dispatching strategy. 
Specifies that the method will be overridden by this class 

ssr s as to the resoiution method * be used *»■ 
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interface D : B1, B2 
{ 

}; 



Figure 10.1 A multiple inheritance example. 



Stroustrup, 1990). Multiple inheritance is supported by SOM, and the 
class hierarchy is therefore a rooted directed acyclic graph. 

Multiple inheritance introduces the possibility of potential conflicts 
when two superclasses define a method by the same name. SOM uses 
a leftmost precedence rule. This means that the method used will 
belong to the class that was leftmost in the inheritance specification. 
This rule is also known as the first subclass rule. Figure 10.1 presents 
an example in which the class D inherits from both Bl and B2. Both of 
these base classes define a method called f . In SOM, D would inherit 
f from Bl, since it is the first subclass (left on the superclass list in 
the interface clause). 

SOM provides two ways by which the default conflict resolution 
rule can be overridden. The simplest way is to override f in class D 
and manually call one or both of the f implementations in the base 
classes. The other possibility is to change the ambiguity resolution 
rule by using a metaclass method. The default SOM ambiguity reso- 
lution rule is defined in the SOM class SOMClass. The programmer 
can override this by defining a metaclass for class D (instead of using 
the default metaclass SOMClass) and overriding the procedure for 
constructing the class's method table. 



10.1.3 Metaclasses in SOM 

In SOM, every class is itself an object. The class object has methods 
and can be used like any other object at runtime. Since the class is 
itself a SOM object, it must have a class — this is the metaclass (a 
class of a class). The class is then said to be an instance of the meta- 
class. The metaclass defines the methods that can be performed by 
the class. This includes such methods as object constructors (i.e-< 
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by the maxowners method TfinVn ^ ^ Value is SU PP^ 
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addOwner: aPerson 
j max | 

max : = se lf class maxOwners. 
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"self class maxOwners" invokes the maxOwners method on the 
metaclass object to retrieve the common value. 

Suppose now that an instance of CheckingAccount (which names 
its own metaclass) were to invoke the maxOwners methods under the 
metaclass scenario shown by Fig. 10.2. A problem would occur, since 
the CheckingAccountClass metaclass does not implement the 
maxOwners method. When the self class maxOwners code was 
performed at runtime, a method resolution error would occur. 

Smalltalk solves the above problem by not allowing metaclasses to 
be freely named by the programmer. The metaclass hierarchy match- 
es the class hierarchy, and in our example, CheckingAccountClass 
would inherit from AccountClass. SOM provides a different and 
more flexible solution. SOM allows the metaclass to be freely named 
for each class. SOM will then automatically create a Derived 
Metaclass, as shown in Fig. 10.3. This automatic metaclass genera- 
tion will guarantee correct ambiguity resolution, since the explicitly 
specified metaclass is first on the inheritance list. An explicit defini- 
tion of the maxOwners method in our example will therefore always 
be used before an inherited implementation. Derived metaclasses are 
also used when multiple inheritance is involved. In this case the class 
has multiple superclasses, so that the metaclass must inherit from 
multiple sources. 




Metaclass 
Inheritance 



Figure 10.3 The solution: DerivedMetaclass. 
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The first three of these objects are class objects. SOMOb ject is the root 
class for all SOM classes and provides behavior common to all classes. 
It must be created to allow any class (and therefore any object) to be 
created. SOMClass plays the parallel role for metaclasses. Finally, 
SOMClassMgrObject is an instance of SOMClassMgr (and can there- 
fore be created only after SOMClassMgr is). SOMClassMgrObject 
manages the classes used by the application and the environment, 
including the loading of the classes from the class libraries. 



The SOMObjects toolkit provides a library of collection and iterator 
classes. These classes are similar to other commercially available 
library classes implementing various collections such as sets, lists, 
and dictionaries. The benefits for a SOMObjects user of using the 
SOMObjects collection classes over other such class libraries are 
twofold. First, these classes are already provided as part of the toolk- 
it, relieving the user of the work (and the cost) required to integrate a 
new library into the environment. Second, the classes are SOM class- 
es; multiple programming languages and environments may therefore 
make use of the collection classes. IDL definitions are provided for 
these classes to enable this language independence. 

The collection classes are based on work done by Taligent (which is 
partly owned by IBM) and are primarily modeled as C++ collection 
classes. Figure 10.4 shows the hierarchy of the SOMObjects collection 
classes. An additional hierarchy provides classes for iterating over 



10.2 The Collection and Communication Classes 



3omt_MCollectible 
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somf_TDeque 



somf_TSortedSequence 



Figure 10.4 Hierarchy of SOMObjects collection classes. 
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these classes to access the definitions stored in the IR. These classes 
implement the IR application programming interface (API) as defined 
by CORBA. The framework, together with the actual SOM IR data- 
base, provides a CORBA-compliant implementation of the IR and the 
IR interfaces. The SOM IR extends the CORBA definitions by storing 
additional information such as SOM modifiers and providing opera- 
tions to access this information. 

The actual SOM IR database is a set of flat files. Each IR file is con- 
structed by running the SOM compiler with the IR emitter over a spe- 
cific . idl file. The file som. ir is provided with the toolkit and con- 
tains the IR information for the built-in SOM classes. 

The API supported by the SOM Interface Repository Framework 
conforms to the CORBA definitions as presented in Chap. 3. The 
main operations provided by the classes in the framework are sum- 
marized in Table 10.2. The structure of the IR follows the CORBA 
definitions. The SOM IR maintains objects of type ModuleDef , 
Interf aceDef , AttributeDef , OperatibnDef , and so on. The 
Repository object is the container through which access is initiated 
and is accessed using the SOM_lnterf aceRepository macro, using 
SOMClassMgrObject's somGetlnterf aceRepository operation, or 
using the RepositoryNew() method. The SOM IR also provides full 
TypeCode support. 



TABLE 10.2 SOM IR Operations 



Operation 


In Type 


Description 


contents 


Container 


Return a sequence of the contained IR objects. 


describe_contents 


Container 


Return a sequence of ContainerDescription structures for the 
contained objects. 


looJcup_name 


Container 


Return a sequence of objects matching a name. The lookup 
recursively returns all such objects in the containment hierarchy 
under the target container object. 


describe 


Contained. 
XXXDef classes 


Return a Description structure containing the IDL definition 
information. 


within 


Contained, 
XXXDef classes 


Return a sequence of container objects which contain the target 
object 
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created by DSOM whenever an object reference is passed; the client 
program need not be aware of this distribution issue. See Sec. 10.4.1 
for more details. 

■ The implementation repository is used by DSOM as outlined in 
CORBA. implementationDef objects are used as defined by the 
CORBA ImplementationDef interface. 

■ The SOMOA DSOM class implements CORBA's BOA while provid- 
ing a number of extensions. SOMOA uses the SOM compiler and 
the SOM runtime system to implement method dispatching. 
SOMOA also provides some of the ORB interfaces as defined by 
CORBA object adapters (e.g., create) as well as implementing the 
methods required for performing the mapping between object refer- 
ences and object implementation. 

■ DSOM supports the Context object as defined by CORBA. 

■ DSOM provides a full implementation of the CORBA DIL 

10.4.1 DSOM proxies 

SOMDObject objects implement CORBA 1.1 object references using 
proxy objects (see Fig. 10.5). When an object reference is passed to a 
client program, DSOM automatically creates the proxy object in the 
client's address space and makes the connection with the real object 
implementation using its own services. This automatic creation is 
done in a dynamic manner according to the object type. For example, 
if an object reference to an Account object is passed to a client pro- 
gram, DSOM will automatically build an Account_Proxy class that 
inherits from Account as well as from SOMDClientProxy (see 
Fig. 10.6). 

SOMDClientProxy inherits from SOMDObject and provides the 
actual proxy support. In the construction of this new class 
(Account_Proxy), the SOM runtime system is used to dynamically 
create this class for use in the client's address space. Account_Proxy 
will include a method implementation for each Account method that 
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Object 




Figure 10.5 Proxy objects as reference objects. 
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Figure 10.6 Automatic proxy class 
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> Objects that have already been created can be looked up by clients. 
Instead of creating a new object implementation whenever a service 
must be provided, the client may look for an already created object 
implementation. 

■ DSOM also supports externalization of proxy objects. It is possible 
to save references to remote objects by creating a string representa- 
tion for any proxy and later using this external representation to 
reconstruct a usable proxy. The remote object must be identified 
and located. This is done by using the DSOM somdGetldFrom 
Object and somdGetObjectFromld operations. 

• When the remote object is not used by the client, it may be 
destroyed. Operations are provided to release only the proxy, only 
the object implementation, or both.' 

- Finally, the client program will finalize the DSOM runtime system 
by calling sOMD.Uninit and any other SOM finalization procedure. 



10.4.3 Creating remote objects 

DSOM provides various methods for creating objects. These differ as 
to whether the client cares about which server will actually create 
(and contain) the object implementation. The simplest operation is 
somdNewObject. In this case, the client does not care about the actu- 
al server where the object implementation will be instantiated, and 
SOMD_Ob jectMgr is free to use any server that it deems appropriate. 
If the client wants the object implementation to be created in a specif- 
ic server, other creation methods should be used. For example, 
somdFindServerByName can be used to access a specific server. This 
operation creates a proxy object for the remote server on which the 
somdCreateOb j operation may be used to actually create the object 
implementation in that server. Servers may be selected by name, by 
id or by whether the server supports a class specified by the client; 
this last option provides a simple and partial Trading Service. Figure 
10.7 shows the two phases of creating the server proxy and creating 
the object proxy. 

If the object is to be created using a specialized constructor, 
somdNewObject should not be used, since the default construction 
process, somNew, will be inappropriate. Instead, somdGetClassOb.) 
should be used to access the class object, which can then be used to 
invoke the specialized constructor. 



10.4.4 DSOM server programming 

Servers execute and manage object implementations in SOMObjects. 
The sOMDServer class provides instances of default server object . 
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Phase 2 - Creating the Object Implementation Proxy 



Figure 10.7 Creating the server proxy and the object 



proxy. 



S?«™ r ^ e S< ! bC J laSSed 10 provide server behavior 

A server program usually includes the following steps.- 



■ Activation, Server activation is done by the DSOM somdd daemon or 
by a manual process. The somdd daemon runs on every machine that 
provides DSOM support and is used as an "agreed-upon meeting 
place" for clients and servers. This is used by the DSOM runtime sys- 
tem to request service startup. Manual startup can be performed 
either by a command line request or by an application. 

■ Initialization. The server program must go through an initializa- 
tion process that includes: 

1. DSOM runtime system initialization using SOMD_init 

2. Initialization of the ImplementationDef object after retrieving 
it from the Implementation Repository 

3. Initialization of the object adapter using SOMD_SOMOAObject = 
SOMOANew( ) ; 

4. Application-specific initialization 

5. Invoking _impl_is_ready on the SOMOA object to inform the 
server that request processing may be initiated 

■ Processing requests. This is done either by passing control to a 
SOMOA loop (_execute_request_loop) 0 r by maintaining con- 
trol over the main loop within the application and calling _exe- 
cute_next_request multiple times. 

■ Exit By calling _deactivate_impl on the SOMOA object to final- 
ize request processing and by calling finalization routines such as 

SOMD_Uninit and SOM_UninitEnvironment. 

1 0.4.5 The DSOM management objects 

Every server has a server object that functions as the server manager 
together with the object adapter. The default objects supplied by 
DSOM are the SOMDServer object and the SOMOA object. 

The SOMDServer class provides methods for creating objects 
(somdCreateObj), deleting objects (somdDeleteOb j), and finding 
class objects by id (somdGetClassObj). Methods are also provided 
for mapping between SOMObjects and SOMDObjects and for meth- 
ods dispatch for SOM objects. These are used by SOMOA when map- 
ping remote requests to local method invocations. When SOMOA is 
ready to dispatch the request, it calls somdDispatchMethod on the 
SOMDServer object, which will usually invoke SOMObject:: 
somDispatch. The developer may override this default behavior. 

If an object reference is required (for example, for a return value), 
SOMOA is used to create SOMDObject references using create, 
create_construct, or create_SOM_ref . Each of these has a 
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Figure 10.8 Example class for object replication. 



developer, as shown in Fig. 10.8. By inheriting from SOMRReplicbl, 
the new class will support replication semantics. Support for the 
Replication Framework is also provided by the SOME : class An 
instance of this class must therefore be created if the Replication 
Framework is used. . . 

The Replication Framework uses socket type communication for 
propagating the changes between the different replicas. To do this, 
the framework must agree on the ports on which messages are sent. 
The Replication Framework uses a file, called the .scf file, specify- 
ing these attributes. This file is used only for the initialization 
process. Once the communication has been set up, the framework 
does not use any files, allowing it to provide good performance. 

The Replication Framework uses a master-slave protocol. Among 
the replicas, one of the objects is the master. All propagations are 
actually done by that one object. This means that when any object 
desires to make a change, it will inform the master, and the master 
will then propagate the change. During the change, no other replica 
may ask for a change (this is similar to a lock being formed by the 
master). The number of messages for a single update for N replicas is 
therefore either N - 1 (if the master performed the update) or N + 2 
(one message to effectively obtain the lock, one to send the update to 
the master, N - 1 messages for the update, and one to release the 
lock) The updates will always be serialized, since the master provides 
the "monitor segment." In addition, the master will always send the 
messages to the replicas in the same order, so that no matter which 
replica triggered the change, the order in which the replicas receive 
the change remains the same. The Replication Framework includes 
algorithms supporting fault tolerance that will elect a new master it 
the master replica should go down. 

10.5.1 Operation and value propagation 

The Replication Framework supports two propagation models, in 
operation propagation, the actual method which causes the change . 
propagated. If one of the replicas is modified as a result of invoking 
method on it, then the method specification is propagated to the otn 



10.5.2 Directives 
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TABLE 10.3 SOM Replication Framework Events 



Directive 


Description 


LOST_CONNECTION 


Connection with other replicas has been lost but attempts to 
reestablish it are being made; no updates to the replica should be 


CONNECTION_REESTABUSHE D 


Connection to the other replicas has been reestablished. 


BECOME_STAND_ALONE 


The Replication Framework has given up trying to reconnect to the 
other replicas. 


LOST RECOVERABHJTY 


The .scf file cannot be updated. 



the connectivity and availability of the different replicas. The actual 
propagation management is done by the Replication Framework 
classes, yet the participating objects must have a way of being 
informed of changes to the connection topology. This is accomplished 
through the use of directives. Directives are methods that are sent 
from the Replication Framework classes to the applications using the 
replicas and inform them of events such as network faults. Examples 
of such events are shown in Table 10.3. To accept directives and pro- 
vide a response, the application should override the somrDo 
Directive method which is called by the Replication Framework 
classes with an argument specifying the directive string. 

1 0.6 The Event Management Framework 

The Event Management Framework provides support for registering 
interest in events and receiving notifications when an event occurs. It 
is similar to event handling in most windowing systems and other 
event managers (e.g., Teknekron, 1994). Using the event manager in 
SOMObjects involves registering interest in the event (by providing a 
callback specification to be invoked when the event occurs) and pass- 
ing control to a central framework function that never returns. The 
program will invariantly remain in that function until one of the 
events takes place. At this time, the callback function will be invoked. 
When the callback function terminates, control is passed back to the 
main loop function; this is depicted in Fig. 10.10. 

The Event Management Framework is extensively used by DSOM 
and by the Replication Framework. Any interactive applications 
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IDL. The SOM compiler is then used to produce a translation of these 
interfaces to the native programming language or programming envi- 
ronment in which the implementation is actually done. SOM is 
intended to support many programming languages and to produce a 
common framework to be used by many programmers, using many 
programming languages, on many operating systems, running on 
many hardware platforms. For each such programming language that 
will be used with SOM, an IDL compiler must be produced; this will 
enable translating the IDL definitions to that programming language. 
To facilitate and ease the production of such translators, the 
SOMObjects toolkit includes the Emitter Framework. 

The Emitter Framework is designed to allow developers to write 
extensions to the SOM compiler. Such extensions can be used to write 
any translator for the IDL specifications. These translators take the 
form of "emitters" which emit translated components derived from 
the IDL specifications and translation rules and formats. These emit- 
ters can then be embedded in the IDL compiler to allow for the new 
translation. This is mainly useful for programming language bindings 
for IDL, but it is also very useful for other purposes, such as generat- 
ing automatic documentation from the interface definitions and deriv- 
ing component information which can be used by CASE tools. 

Figure 10.11 illustrates the function of the Emitter Framework 
components. The IDL interfaces and definitions are read by the IDL 
parser to produce an Abstract Syntax Graph (ASG). This graph repre- 
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Figure 10.11 The Emitter Framework compo- 
nents. 
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table 10.4 SOM Emitter Framework IDL Default Sections 



prologs 


Information that is emitted before any other. 


AttrihuteS 


Class attribute information. 


methods 


Class method information. Is invoked iteratively for every method in the class. 


interfaces 


Information for the interface. 


modaleS 


Module information. 


baseS 


Information about the parent classes; used when a class inherits from others. 


epilogS 


Information emitted after all others. , a 



Creating, a new emitter typically involves two things: the emitter 
and the template. First a subclass of SOMTEmitC is created to provide 
specialized control of the translation process. The somtGenerate 
Sections is the method that is most commonly overridden to provide 
the customized specification determining what is emitted and in what 
order. This is done by attaching emitting methods for standard sec- 
tions of the IDL. Some of the default sections are given in Table 10.4. 
Each of these sections has a method which is used to emit the section. 
By overriding the default definitions of these methods, customized 
emitter behavior can be defined. 

Once the emitter class has been defined, the output is created by 
rendering the syntax graph on the template definition. The template 
defines the output format, locations, and symbols which will make up 
the resulting files. Template creation is a simple yet very powerful 
process. It is very easy to create emitters in a matter of minutes or 
hours for more complex translations, since much of the specification 
goes into the template definitions. 



10.8 The Persistence Framework 

The SOMObjects Persistence Framework provides persistence sup- 
port for SOM objects. The Persistence Framework allows SOM objects 
to be stored in files, which allows the objects to exist after program 
termination. The objects can later be reconstructed to the internal 
representation. In many respects the Persistence Framework is really 
an externalization/internalization framework. However, th* 
Persistence Framework is not limited to using external files; it can tx 
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The group manager class name defines what class will be used to 
store the object. The group name defines where the object will be 
stored, and the offset specifies where precisely in the group the object 
will be stored, since multiple objects will typically be stored in a sin- 
gle group. 'For example, the default group manager class is 
SOMPAscii, so a possible persistent OID might be 



SOMPAscii:myfilename:0 



where myf ilename is the name of a file. The SOMPAscii manager 
uses ASCII files for the persistence of objects; myf ilename would 
therefore be the file in which the object would be stored at offset zero. 

Persistent OIDs may be associated with an object in one of three 
ways: 

1. An OID can be explicitly created (by creating and populating a 
SOMPPersistentld object) and associated with the object using 
sompInitGivenld. 

2. A sOMPAssigner object can be used to create an OID (using 
sompInitNextAvail) and associate it with the object. 

3. The developer may request that the object be placed near another 
object and the OID derived accordingly (a simple form of object clus- 
tering). 

The last method is the one which is most commonly used. Typically only 
one object will be explicitly given an OID and the rest of the objects will 
be given OIDs by placing then near a previously identified object. 

Groups are the unit of object storage and are collections of objects 
stored together in a single file (or some other persistent organization). 
Groups are represented in the Persistence Framework as instances of 
SOMPlOGroup and are associated with a group manager object (whose 
class derives from SOMIOGroupMgrAbstract). The group manager 
defines how the objects are stored, whereas the group specifies where 
the objects are stored. 

The SOMObjects Persistence Framework supplies two built-in 
group managers: SOMPAscii and SOMPBinary. SOMPAscii is the 
default group manager; it stores each group as a single ASCII file. 
The SOMPBinary group manager is similar, but it stores the data in a 
binary format (e.g., the number 17 will not be stored as two charac- 
ters T and U T but as the binary representation of 17). Both the 
SOMPAscii and the SOMPBinary group managers have similar char- 
acteristics. The SOMPAscii group manager is usually used at the ini- 
tial development stages, since it is easier to debug (since the storage 
can be viewed in a text editor), and is later replaced by the 
SOMPBinary group manager, since it is more efficient to use. 
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Decoder, the developer would use the sompSetEncoderDecoder 
Name method to associate it with a single object or the sompSet 
ClassLevelEncoderDecoderName if the Encoder/Decoder is to be 
associated with a class of objects. 



10.8.3 Saving and restoring 

The saving and restoring process uses the framework components as 
described above. The steps performed when storing (externalizing) an 
object are: 

■ Create a Persistent Storage Manager (PSM) by using the 
SOMPPersistentStorageMgrNew method to instantiate the SOMP 
PersistentStorageMgr class. This initializes the Persistence 
Framework. 

■ Create the object to be stored. 

■ Assign a persistent OID to the object in one of the three ways 
described above. 

■ Use the sompStoreOb ject method to store the object based on the 
information in the persistent OID. 

To restore the object, the following steps are followed: 

■ Initialize the Persistence Framework as above. 

■ Create a new persistent OID object using SOMPPersistentldNew; 
this is not a persistent object but a persistent OID. 

■ Assign the actual OID to the persistent OID object using somutset 
IdString. 

■ Use sompRestoreObject to restore the object. 

■ Use somFree to free the persistent OID object. 

The saving and restoring process also incorporates a passivation/acti- 
vation process. Just before storing the object, the Persistence 
Framework calls the object's sompPassivate methods, and just after 
restoring the object, the sompActivate method will be invoked for 
that object. These methods are defined in SOMPPersistentObject 
but should be overridden by objects which have to supply specialized 
activation or passivation behavior. 

Once the object has been stored, the PSM provides various manage- 
ment capabilities. For example, the sompObjectExists method can 
be used to determine whether an object with a certain persistent OID 
exists. An object can be deleted from its persistent store using the 
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AUTONOMOUS AND MOBILE AGENTS IN DISTRIBUTED NETWORK MANAGEMENT AND 
MONITORING SYSTEM 

UMA SHANKER, Innovative Network Applications, IBM Scientific Center, 18 Vangerowstrasse, Heidelberg 
69115, Germany Email : uma@de.ibm.com , Tel : ++49-6221-594560, Fax : ++49-6221-593300 

Abstract Distributed object technology provides optimum architecture for Internet and intranet web 
applications. This paper presents a generic architecture solution for the Network Management System. Central 
to the distributed network management is the broker which provides access to the real-time information from 
the network nodes. It explains how the broker is used to manage and access management data on real-time 
basis. Finally we talk about the autonomous and mobile agents in the given architecture. It explains use of 
design patterns like broker, proxy etc. and some details and experiences from the ongoing project are described. 
Areas for future research are also explored. 

Keywords : Agents, Network Management, CORBA, Java, SNMP 

1 INTRODUCTION In todays growing internet its very inportant to have upto-date information about your 
systems components and it becomes more important if you are internet provider. Increasing size and complexity 
of network and the need to support all sorts of advanced services in a reliable and cost-effective maimer pose a 
major challenge to network management. 

The traditional approach to develop large complicated network mangement/monitoring systems and 
applications was to build them using a uniform platform-specific architecture, based on openly defined 
management interface such as defined by SNMP [6] management framework. In the traditional model, a 
network management application's user interface is provided by an 

appropriate data-driven protocol to a windowing or other display(like in SunNet Manager[2] from Sun). Recent 
advances in technology such as WWW[3] browsers and services, corporate intranet, and executable contents 
such as provided by Java[7], introduce the possibility for a more network-centric approach to the development 
of management applications, that allows organisations to leverage their existing Network Management System 
(NMS) solutions with generic, highly scalable and customizable Web-based front end. Network management is 
data-based. Vast amount of information(especially in large, complex networks) are collected by the network 
agents[l] and sent to the manager site. Manager site collects network performance, status and configuration 
information, maintains historical and statistical data, handles events and reports. All this information, which 
explodes in size with network complexity and size augmentation, need not only be stored efficienty but it must 
be enriched with powerful data management features that allow the relization of demanding, high level 
management functions like temporal reasoning, decision-making, planning etc. Additional functionalty is also 
required in large multiple domain network environments. As we come into Web-based front end system, there 
are several places which are very critical to the performance and reliablity of the system. Very first point is, 
how to handle data in the reliable and easy way? Security is yet another important issue. We propose the 



http://64.233. 161.1 04/search?q=cache:yKRwkFlZdB AJ:www.ctr.kcl.ac.uk/members/shanker/shan... 1/20/2006 



Page 2 of 5 



Distributed Network Management and Monitoring System(DNMMS) architecture, which is based on Java[7] 
and Object Request Broker[l 1]. We are using Voyager from objectspace, as in addition to the fundamental 
ORB features it also support mobile objects, autonomous agents, events and listeners, database independent 
persistence, directory services etc. On the other side, we are using Java due to its ability to load classes into a 
virtual machine at run time. This capability enables infrastructures to use mobile objects and autonomous agents 
as another tool for building distributed systems. DNMMS architecture is shown in figure 1. 

2 BACKGROUND Various Tools/Systems are available today in the market for System Management and 
Monitoring. Please note that we are using the term System management and not Network Management, as in 
todays distributed environment, Internet providers are not only interested in there network components like 
routers, but also in there web-applications like http and proxy servers and they like to have common interface 
for all the management applications. Generally these tools runs on different Platforms and generally not 

Figure 1: Architecture of DNMMS compartible with each other. Extension/upgrading is also very difficult. 
Now a days one of the common way to provide the statistics about the systems like web, routers, nodes, etc. 
using web-front end is to collect the statistics information at regular time interval at central location, where the 
data is formatted(mainly by CGI) for the administrator to display the data in the web browser. But CGI is a 
state-less technology, so we don't have any persistent state during the browsing. In general all of the data, some 
of them are never used by any body, is transmitted from the nodes to the central location. There is no 
connection with the system once data is retrived. If we want to have further special query about some 
node/machine, we have to use some other system or all the queries are done at the central location but not at the 
node/machine, which makes that tool not real-time and hence not 100% reliable which is necessary for the 
network components(routers/proxy/web servers) of the Internet Service Providers. Next section explains 
architecture of the Java/Corba based DNMMS system and also the extension and integration of existing tools. 

3 OVERVIEW OF DNMMS 3.1 DNMMS Architecture Central to the DNMMS architecture are two 
components CountryBase and Embassy. CountryBase is implemeted according to the Broker Pattern[10]. 

On one side it collects management information from the network nodes and provides facilities for the real-time 
management data, on the other side it is used by the front end to present management data in the visual 
(graphical/text) format. Please note that frond end can be application or applet, which can access CountryBase 
by DNMMS API. 

Embassy is based on the Proxy Pattern. It is situated at network nodes which provides data from that node 
according to the standard interface. Interface to the Embassy is described in the IDL format, which allows its 
implemetation in different programming languages like Java, C++. As Embassy will be running on different 
platforms, it allows to have optimal implementation for that platform. It gives possibilities to integrate existing 
management systems. Each network node can have several management objects. Every management object is 
described by its mangement object identifier(MOI). CountryBase requests management data from Embassy by 
providing MOI. MOI completely specifies manageable resource inside the DNMMS. 

You can compare the DNMMS as a country, who has there embassies located at other foreign countries 
(different servers, routers). Most important is that Embassies are not engaged with the foreign countries 
government. They just provide the required information within the protocol set by the two countries. Inside 
DNMMS every object like embassy, agent, etc. have unique identification numbers called GUID (16-byte 
globally unique identifier). 

3.2 CountryBase overview CountryBase is based on the Broker Pattern[8]. It is responsible for coordinating 
communication, such as forwarding requests, database and directory services as well as for transmitting results 
and exceptions. Instead of focusing on low-level inter-process communication, it allows to access distributed 
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services simply by sending message calls to the appropiate Embassy. In addition, the CountryBase architecture 
is flexible, in that it allows dynamic change, addition, deletion, and relocation of MOI. CountryBase just 
transmits requests made by the client to the appropiate Embassy. In general CountryBase is responsible for : 

ffl Registration of embassy ffl Transfers of messages ffl Error recovery ffl Interoperation with other brokers 

ffl Locating embassies ffl Directory services ffl Agent management ffl Storage of management data 

CountryBase has a central distributed database which stores all the management data collected from the 
different embassies and also data to manage CountryBase itself. Every information exchange between a client 
and Embassy passes through the broker. 

3.3 Embassy Overview Embassy is based on the Proxy pattern[9]. It is installed at every network node and it 
provides data from that node according to the standard interface. Embassy during the initialization process 
registers himself with the CountryBase. Embassy can be started through remote machines as all the classes 
needed for the Embassy can be automatically downloaded. This allows easy installation and management. 

Client make request by providing MOI to the Embassy. After receiving request Embassy works according to the 
local implementation and provides back the result. General format of MOI is 

MOI://PROTOCOL/VERSION/OI/ where PROTOCOL is a name of protocol like SNMP, VERSION is a 
version of the MOI implmentation and 01 is a Object Identifier, eg. in case of SNMP 01 can be 1.3.6.1.2.1.7.1 
for the UdpInDatagrams. Please note that this format on the one side allows to use industry standard like SNMP 
but are not only limited to that. All informations related to MOI are available through the CountryBase 
Directory Service under [/CountraNet/MOI ]. Example of MOI is : MOI://SNMP/1.0/1.3.6.1.2.1.7.1/. 

Interface to the Embassy is described in the IDL[5] format, which allows its implemetation in different 
programming languages like Java, C++. As Embassies may will be running on different platforms, so there 
implmentation can be different. Working of DNMMS using ORB and MOI is shown in figure 2. 

4 AGENTS IN DNMMS 4.1 Agents in CountryBase DNMMS Agents are the voyager's mobile objects, they 
can move at run time from one virtual machine to another. In this way, agents can act independently on the 
behalf of a client, even if the client is disconnected or unavailable. CountryBase has central directory to hold 
every neccessary information to operate Agents in the DNMMS. Each Agent in the DNMMS is associated with 
unique identification number called AUID, which is 

Figure 2: ORB and MOI working in DNMMS a GIUD of that Agents Virtual Reference^]. All the 
informations are stored in central directory on CountryBase in [/Agent]. As the agent proceeds from embassy to 
embassy agent related data are stored in this central directory. This provide one point management of all the 
agents in DNMMS. This provides facilities to check status of different agents in DNMMS. Further 
enhancement can be done by providing agents related information on date, status, last logged, etc. basis. 
CountryBase is a central location to execute commands like start, stop, wait etc. on the agents. 

4.2 DNMMS System Agents There are serveral DNMMS agents which are started at the CountryBase creation 
time. These agents are DNMMS System Agents and are generally live forever status[4]. They are used to 
manage DNMMS itself. 

4.3 DNMMS Management Agents DNMMS management agents are the agents which can be used to monitor 
status of the network nodes. These agents are completely autonomous. It means that they can control themselfs 
in different situations. An agent is a special object type. An agent has autonomy. An autonomous object can be 
programmed to satisfy one or more goals, even if the object moves and lost contact with his creator. Using 
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voyager DNMMS supports autonomous and mobile agents, mobility is the ability to move independently from 
one device to another on a network. When agent moves to new location , he leaves behind a forwarder to 
forward messages. 

If the agent want to have high-speed conversation with remote object, the agent can move to the object and then 
send it local Java messages. 

Autonomous agent in DNMMS is useful for many reasons, for example: 
ffl If a task must be performed independently of the computer that launches 

the task, a mobile agent can be created to perform this task. Once created, the agent can move into the network 
and complete the task in a remote program. 

ffl If the periodic monitoring of a remote object(in our case object return 

back the status of himself at the CountryBase ) is required, creating an agent that meets the remote object and 
monitors it locally is more efficient than monitoring the device across the network. 

Agent knows nothing about the remote location address and other useful informations which is needed to access 
that location. Agent gets all these information from the CountryBase Directory Service. Once agent has virtual 
reference of the remote embassy he can use it to find out other informations like, GUID, network address, port 
and so on. As a example, there can be agent which goes to the target Embassy and tries to monitor the tcp 
segments received and send. If it increases 2000 segments/sec then agent reports to the output. Please note that 
any other action can be taken on this event. Agent can finally move to the CountryBase or can be parked at the 
Embassy or can send some notification and so on. 

5 CONCLUDING REMARKS The growing complexity of the network infrastructure requires a reliable and 
real-time management system. A web-based, network centric design gives the flexibilty to offer such a solution, 
and additionally allows one to scale up the solution because of its genericity. We believe that architecture 
presented is one of the first such application of its kind. But there are still some important open issues like 
security, performance and workload. 
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